|
The Microsoft Visual Studio Debugger is a debugger that ships along with all versions of Microsoft Visual Studio. This debugger owes much of its feel and functionality to CodeView, a standalone, text-based debugger that shipped with Microsoft Visual C++ version 1.5 and earlier. More advanced features of the most recent versions of this debugger include: * Full symbol and source integration. * Edit and continue support, enabling source code to be modified and recompiled on-the-fly without having to exit the current running program or restart the debugger (32 bit applications only). * Remote machine debugging. * Attaching and detaching to and from processes (both on the current machine and a remote machine). * Integrated debugging across programs written in both .NET and native Windows languages (calls from C# to C++, for example). * Full support for C++, including templates and the standard library * Debugging ASP.NET Web Services. * Tracing into DLL code when symbolic debugger information is present. * Standard as well as more advanced breakpoint features, including conditional, address, data breakpoints. * Many ways of viewing program state and data, including multiple watch windows, threads, call stack, and modules. The way library and user data types are displayed can be configured (e.g., to show contents of a container class, rather than its raw structure). * Scriptability or the ability to control via a macro or scripting language. Any language which can talk to COM can be used. * Local and remote debugging of SQL stored procedures on supported versions of Microsoft SQL Server. The main shortcoming of the Visual Studio Debugger is its inability to trace into kernel-mode code. However, this is possible using a free VisualDDK extension. Alternatively, kernel-mode debugging of Windows is generally performed by using WinDbg, KD, or SoftICE. The Visual Studio Debugger also has no ability to debug Lambda-Expressions or LINQ. This is because it would take too much work for Microsoft to implement.〔http://blogs.msdn.com/b/jaredpar/archive/2009/08/26/why-no-linq-in-debugger-windows.aspx〕〔http://blogs.msdn.com/b/jaredpar/archive/2010/06/02/why-is-linq-absent-from-debugger-windows-part-2.aspx〕〔http://connect.microsoft.com/VisualStudio/feedback/details/472999/ability-to-evaluate-lambda-expressions-in-immediate-window〕 However, most developers working with Lambda expressions are able to visualize the data through the several memory windows or by storing the result into a variable. Edit-and-continue is held by many developers as Microsoft's greatest asset given to developers. A program that is running in memory, that encounters a simple mistake, can be corrected without having to stop the current program or exit the debugger. This feature allows very common mistakes to be corrected easily and with great time savings over other solutions which require exiting the program, making the change, recompiling, and then navigating back through the running program to the previous location. == References == 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Microsoft Visual Studio Debugger」の詳細全文を読む スポンサード リンク
|